Summary by CodeRabbit

• New Features

  • Zero-amount wrap, supply, withdraw, and unwrap actions are now accepted and marked with a non-blocking ZERO_AMOUNT flag.

• Bug Fixes

  • Improved validation handling so valid transactions with zero amounts are no longer rejected in supported flows.

• Chores

  • Bumped the package version to 1.3.1.

Shield now accepts zero-amount ERC-4626 transactions for recognized operation
patterns instead of rejecting them. Previously, a zero-amount deposit/withdraw/
redeem/unwrap was hard-blocked ("… amount is zero"), which surfaced to clients
as the aggregate "No matching operation pattern found" error — the root cause of
the redeem(0) false blocks seen in production soak (ENG-2372).

Why this approach: we don't know why clients construct zero-amount txs
and don't want to break unknown flows. A zero-amount transaction is a no-op with no
visible security risk, so blocking it adds friction without protection. This
supersedes the earlier plan to reject amount <= 0 upstream in the monorepo with a
412.

Scope is amount-only. Acceptance does not loosen any other invariant. A
zero-amount tx still must pass every existing check — whitelisted vault, correct
selector, no stray ETH value, and owner/receiver must equal the user/expected
address. Only the amount === 0 short-circuit is removed.

Telemetry. When an accepted transaction has a zero amount, the result now carries
a non-blocking details.flags: ['ZERO_AMOUNT'] signal so we can observe how often and
why clients send these, and revisit a targeted block later if the data warrants it.

Changes

• src/types/index.ts — add optional details.flags?: string[] to ValidationResult.
• src/validators/base.validator.ts — safe(flags?) can attach non-blocking flags.
• src/validators/evm/erc4626/erc4626.validator.ts — remove the zero-amount blocks in
  validateSupply, validateWithdraw, validateUnwrap, and validateWrap; emit
  ZERO_AMOUNT when the amount is zero. Receiver/owner checks are unchanged and still run.
• src/validators/evm/erc4626/erc4626.validator.test.ts — flip the four zero-amount
  reject-tests to assert acceptance + flag; add guard tests proving a zero-amount tx is
  still blocked when the vault is not whitelisted, the receiver mismatches, or the owner
  is not the user.
• package.json — 1.3.0 → 1.3.1 (backward-compatible behavior change).

approve(0) is unchanged — the approval validator already ignores the amount (USDT
zero-allowance reset), and is the precedent this change follows.

QA Proof

Full Shield test suite green (10 suites, 5922 tests) with the flipped zero-amount
acceptance cases and the new amount-only guard tests:

What Needs to Be QA'd in Staging

• Deploy with SHIELD_MODE=MONITOR; send a zero-amount redeem(0)/withdraw(0)
  on a whitelisted ERC-4626 yield and confirm logs now show
  Shield validation successful (was Shield validation failed /
  No matching operation pattern).
• Confirm the ZERO_AMOUNT flag is present on the accepted result.
• Regression: a zero-amount tx with a tampered owner/receiver (not the user)
  is still blocked.
• Regression: normal non-zero deposit/withdraw/redeem still validate as before
  (no flags on the result).
• Zero-amount tx to a non-whitelisted vault is still blocked.

QA Team Notification

• QA team has been notified to test in staging.